The present invention generally relates to an event recognition unit for recognizing and/or monitoring events on an information bus.
There are several possibilities known in the art to recognize events in a data processing unit such as a personal computer (PC), a workstation, or the like. The term xe2x80x98eventxe2x80x99, as used herein, shall refer to any kind of occurrence of significance, e.g. a dead lock situation (xe2x80x98transfer does never completexe2x80x99), a dead system (xe2x80x98no bus traffic after x clocksxe2x80x99), an access to an address A by an agent B, or the like.
Events occurring in the data processing unit are normally recognized (and might further be captured) by monitoring data communication facilities such as data busses, whereby the term xe2x80x98data busxe2x80x99 shall refer to any kind of data connection as known in the art.
FIG. 1 depicts an event counter 5 for real-time counting as a device for event recognition as known in the art. A comparator 10 receives at least one input signal to be observed on an input bus 20. The comparator 10 monitors the input bus 20 for a predefined-pattern (also referred to as pattern terms) and provides a count signal on a line 30 to a counter 40, e.g. a logical xe2x80x981xe2x80x99 in case of an observed event (i.e. the predefined pattern has been detected). Generally speaking, a pattern (term) is a logical term which can result in either a logical xe2x80x980xe2x80x99 or a logical xe2x80x981xe2x80x99. It can comprise any logical relationship between bus patterns and pre-programmed terms. These relationships can be mask/value combinations (like xe2x80x9cAD32==000b8xxx hxe2x80x9d), ranges (like xe2x80x9csignal  less than =7 andand signal  greater than 1xe2x80x9d), lists (like xe2x80x9ccmd==7|cmd==3|cmd==9xe2x80x9d), or the like. It can be generally stated that a pattern term""s value consists of a variable part and of a fixed part.
A pattern on input bus 20 is detected when for each of the signals, that input bus 20 consists of, one of the following conditions is met: the input signal is in the logical xe2x80x980xe2x80x99 state or in the logical xe2x80x981xe2x80x99 state or is in any logical state (don""t care), dependent on its specification. The number of events in the input signal on the input bus 20 is thus counted by the counter 40.
The term xe2x80x98countersxe2x80x99 as used herein shall apply to devices, such as registers or storage locations, which are used to represent a number of occurrences of an event. Counters are normally used in conjunction with a filter or trigger module for real time counting of a specific event.
The comparator 10, or another filter or trigger module, ergo selects, according to the predefined pattern, whether or not the occurred event will be counted by the counter 40. A more illustrative example to understand the function of the conventional event counter 5 could be a task to measure all red cars traveling from a point A to a point B. The comparator 10 (as filter or trigger task) would select the red cars on the input bus 20 only and send this information via line 30 to the counter 40 which counts the number of red cars as the filtered or triggered events.
Event counters 5 are often applied for performance measurement purposes. The performance represents the degree to which a system or component accomplishes its designated function within given constraints, such as speed accuracy or memory usage. The performance can be defined e.g. by the ratio of the number of specific events to all events, or by the number of events per time unit.
For performance measurements (e.g. xe2x80x98the percentage of red carsxe2x80x99), the input bus 20 might further be coupled to an input information counter 50 counting all events in the input signal on the input bus 20, whereas the event counter 5 will only count specific events defined by the specific pattern. The counter 40 of the event counter 5 and the input information counter 50 are coupled to a processing unit 60 which determines the performance on the input bus 20, e.g., by dividing the content of counter 40 by the content of the input information counter 50. The input information counter 50 can basically be built up in accordance with the event counter 5.
The information as received from the performance measurement according to FIG. 1 provides only a limited information about the actual performance on input bus 20 which might not be sufficient for certain applications.
Another known device for event evaluation is a so-called trace memory 70. The trace memory 70 comprises an event recognizer 80 which is coupled via a line 85 to a memory 90 for controlling a read/write access of the memory 90 on the input bus 20. The memory 90 stores events recognized by the event recognizer 80. The trace memory 70 thus allows to reproducible xe2x80x98tracexe2x80x99 events e.g. for logic analyzing. The event recognizer 80 normally allowsxe2x80x94dependent on a recognized eventxe2x80x94to either move to a successive state, to jump to a predefined state, or to stay in the current state. This, however, might not be sufficient for applications that are more complex.
For the purpose of initiating bus transactions (i.e. a write access to a system memory via a PCI bus), a system Hewlett-Packard HP E2910A, introduced by the applicant, uses a plurality of comparators in combination with a sequencer state machine as an event recognition unit 100, as depicted in FIG. 2. The event recognition unit 100 comprises one or more comparators 110a . . . 110z coupled to an information bus 120. An output of each one of the comparators 110a . . . 110z is coupled via a line 130a . . . 130z to a sequencer state machine 140. The sequencer state machine 140 comprises a memory 142 and a register 144, whereby one or more outputs of the register 144 are coupled back to one or more inputs of the memory 142 as indicated by line 146. The coupling back allows the sequencer state machine 140 to move between different states, whereby the specific state of the sequencer state machine 140 is not constant but depends on the history of information as provided thereto. The sequencer state machine 140 further receives a clock signal CLOCK on a line 150, and eventually provides an output bus 160 for initiating the bus transactions.
In the HP E2910A, the comparators 110a . . . 110z monitor the information bus 120 for predefined event-patterns (in accordance with comparator 10 in FIG. 1) and thus signal occurring events to the sequencer state machine 140. The sequencer state machine 140 moves from one state to a next state according to the information as provided on its inputs 130a . . . 130z, 146, and 150. When the sequencer state machine 140 reaches a certain predefined state, it will initiate a corresponding bus transaction by means of respective output signals applied to the output bus 160.
A system Hewlett-Packard HP E2925A, again introduced by the applicant, uses the concept of the event recognition unit 100 for analyzing data streams on the information busses 120a . . . 120z e.g. for applied protocols or information data, thus allowing monitoring and analyzing time information and correlations between events.
FIG. 3 shows a data-analyzing unit 200 of the Hewlett-Packard HP E2925A. The data-analyzing unit 200 comprises an event recognition unit 205 as an enhancement of the event recognition unit 100. The one or more comparators 110a . . . 110z are coupled to one or more information busses 120a . . . 120z, respectively. The information busses 120a . . . 120z can represent one single information line, a plurality of individual information busses, or combinations thereof, and may also be coupled to one information bus 120. A sequencer state machine 140A according to the invention, which basically corresponds to the sequencer state machine 140, may further receive a clock signal CLOCK on a line 150, and provides one or more output busses 160a . . . 160z. The sequencer state machine 140A will move from one state to a next state according to the information as provided on its inputs, e.g., on the lines 130a . . . 130z, on the line 150, and/or output 220a. This move between different states is indicated by a state loop 180, which illustrates that the specific state of the sequencer state machine 140A is not constant but depends on the history of information as provided thereto.
Sequencer states, outputs, and transition conditions of the data-analyzing unit 200 have to be programmed in a xe2x80x98programming modexe2x80x99, and the data-analyzing unit 200 is then started and put in xe2x80x98run modexe2x80x99 to operate.
Modern self-configuring information bus systems work with data patterns which might not already be called until runtime of the system when they are configured. In order to capture relevant data, it becomes necessary to do a test run, take note of the values of the respective configuration data, and re-program the data-analyzing unit 200 with these values. This only works when that data does not change on subsequent runs. When configuration data changes dynamically, capturing is not possible at all.
It is therefore an object of the present invention to provide an improved tool for monitoring and/or processing events occurring in a data processing unit, in particular when configuration data or event patterns change dynamically.
The object is solved by the independent claims. Preferred embodiments are shown by the dependent claims.
According to the invention, an event recognition unit is provided with an output loop for dynamically setting (programming or reprogramming) comparators of the event recognition unit. Thus, the event recognition unit according to the invention can dynamically react to event patterns on the bus that are not known at programming time.
An event recognition unit according to the invention comprises one or more comparators coupled to an information bus. Outputs of the one or more comparators provide inputs of a sequencer state machine. One or more outputs of the sequencer state machine are coupled back to one or more of the comparators thus allowing to dynamically program or reprogram the comparators, e.g. in accordance with monitored events at runtime.
The programming output loop from the sequencer state machine can change the pattern terms of the comparators either directly by directly setting new (fixed and/or variable) values of the pattern terms, or indirectly by causing the comparators to receive new pattern terms e.g. from the information bus. Using the programming output loop allows that in reaction to certain events on the information bus a program output can be activated causing a corresponding pattern term to be modified as a dynamic pattern term.
In one embodiment, programming or reconfiguring is accomplished in that on an active programming output, the respective comparator loads new (fixed and/or variable) value settings. The can be determined e.g. by the state of the information bus (example: load current state of AD32-line) or by other inputs. All of these input values can be masked, i.e. only relevant parts will be programmed. Programming new variable settings provides means to react to events of which the value ranges are not known at programming time, e.g. the size of an address range. Both fixed and variable values themselves can be masked by a xe2x80x9cprogramming maskxe2x80x9d.
In a preferred embodiment, dynamic pattern terms can have a xe2x80x9cvalid-bitxe2x80x9d determining whether the pattern has been programmed yet. If the valid-bit is set to xe2x80x9cinvalidxe2x80x9d, the pattern term of the comparator will never match until it is configured. Programming of the pattern term will set the valid-bit to xe2x80x9cvalidxe2x80x9d.
The invention augments possible recognizing events by dynamically reacting to previous events. The xe2x80x9cstate historyxe2x80x9d of the sequencer can be complimented by an xe2x80x9cevent historyxe2x80x9d represented in the dynamic pattern terms. Information on the bus cannot only be captured at specific points in time (as e.g. in a trace memory) but may also be used for triggering further events occurring at later points in time.
The invention is preferably directly implemented in hardware, since software solutions analyzing capture data and reprogramming the pattern terms will not achieve the short reaction times needed in fast systems. In hardware implementations, the reaction time can be provided in the order of clocked cycles. For devices not having a microprocessor or microcontroller, software implementations are impossible.